巴西专利BR112016010845A2 ? METHOD FOR GENERATING AND RECOVERING ENCRYPTION KEYS BY A CLIENT DEVICE?

专利PDF首页>>巴西专利

专利附录

专利说明

权利要求

类似技术

同族专利

引用文献

法律状态

优先权

专利摘要:
METHOD FOR GENERATING AND RECOVERING KEYS OF ENCRYPTION BY A CLIENT DEVICE.Systems and methods are provided to generate subsequent encryption keys by a client device as one of a plurality of client devices on a network. Each client device has the same key generation information and the same key configuration information as an authentication server. Each client device maintains and stores its own key generation information and key configuration information. Using their own information, each client device generates subsequent encryption keys that are common or the same across devices. These subsequent encryption keys are generated and maintained on the devices without any additional instructions or information from the authentication server or any other client device. Additionally, client devices can retrieve the current encryption key by synchronizing information with another client device.
公开号:BR112016010845A2
申请号:R112016010845-0
申请日:2014-11-11
公开日:2020-08-18
发明作者:Michael Demeter；Stephen Chasko
申请人:Landis+Gyr Innovations, Inc.；
IPC主号:

专利说明:

[2] [2] This disclosure generally refers to updating an encryption key on devices on a network and, more particularly, is directed to using a device-generated key as an updated encryption key.
[4] [4] Systems and methods are revealed to generate an encryption key and update it via a client device. Although the encryption keys are generated and updated independently by each client device at periodic intervals, they remain common for the client devices on the network.
[5] [5] In an exemplary method, each client device is provided with key generation information that comprises a derivation method and a derivation index adjustment. A secure channel is established between an authentication server and a client device. The authentication server transmits key configuration information over the secure channel that comprises a bypass key, a bypass index, an initial expiration period, and an expiration interval. Although the client device maintains and stores its own key generation information and key configuration information, this information remains common for devices on the network to allow the generation of subsequent encryption keys that are used for secure communication on the devices in question. a network without any additional communication between the client devices and the authentication server.
[6] [6] In response to the client device receiving key configuration information, the client device generates an initial encryption key based at least in part on the derivation method provided and on the key configuration information previously received from the authentication server that comprise the bypass key and bypass index. The initial encryption key is common for the plurality of client devices on the network and is valid until the initial expiration period previously received from the authentication server expires.
[7] [7] In response to the client device determining that the initial expiration period has already expired, the client device generates a current drop index based on the drop index received previously from the authentication server and the drop index setting. In addition, the client device generates a current expiration period based on the initial expiration period and the expiration interval received from the authentication server. A subsequent encryption key is now generated by the client device based at least in part on the derivation method provided, the derivation key previously received from the authentication server and the current derivation index. Each subsequent encryption key is generated in a similar way so that it is common to client devices on the network and valid until the current expiration period expires.
[8] [8] In response to the client device determining that the current expiration period has already expired, the client device resets the current expiration period to a value based on the current expiration period and the expiration interval previously received from the authentication server. . In addition, the Current derivation index is updated based on the current derivation index and the derivation index adjustment. The next subsequent encryption key is generated using the current updated derivation index and is valid until the expiration of the current expiration period.
[9] [9] A method is also revealed to retrieve the current encryption key from a client device without any communication with or from the authentication server. An exemplary method includes a client device to synchronize its current derivation index and its current expiration period with the current valid derivation index and the current valid expiration period that are currently used by devices on the network to generate a valid current encryption key. . Another example method includes a client device generating a valid current bypass index, a current expiration period, and a valid current encryption key upon receipt of the message that includes the current time.
[10] [10] These illustrative aspects and features are mentioned not to limit or define the invention, but to provide examples to assist in understanding the inventive concepts revealed in this application. Other aspects, advantages and features of the present invention will become apparent after analyzing the entire application. BRIEF DESCRIPTION OF THE FIGURES
[11] [11] These and other features, aspects and advantages of the present disclosure are best understood when the following Detailed Description is read with reference to the accompanying drawings, in which:
[12] [12] Figure 1 is a diagram illustrating the configuration of an authentication server and client devices over a network;
[13] [13] Figure 2 is a diagram that illustrates information used by the authentication server and client devices when generating and maintaining encryption keys;
[14] [14] Figure 3 is a flow chart illustrating the generation of an initial encryption key and subsequent encryption keys;
[15] [15] Figure 4A is a flow chart illustrating a client device retrieving the encryption key;
[16] [16] Figure 4B is a continuation of the flowchart in Figure 4A that illustrates a client device retrieving the encryption key; and
[17] [17] Figure 5 is a flowchart that illustrates a client device retrieving the encryption key after a power outage. DETAILED DESCRIPTION
[18] [18] Systems and methods are provided to generate an initial encryption key and subsequent encryption keys on devices within a network that can be used by all devices on the network. Configuring these devices on a network includes an authentication server communicating with multiple client devices over a network. Network devices (that is, the authentication server and client devices) can be connected in any known way, including both wired and wireless, and can use any type of communication protocol such as the IP protocol.
[19] [19] Multiple client devices communicate with each other and with the authentication server over the network. The devices on the network use the same encryption key; therefore, a common encryption key on devices is used to secure communication between devices. The encryption key can also be used for secure communication between any client device and the authentication server. CRYPTOGRAPHY KEY GENERATION
[20] [20] Each of the client devices within the network comprises a processor and memory. Each client device is provided with key generation information that includes, but is not limited to, a derivation algorithm or method and a derivation index adjustment. In an implementation, the derivation method is based on NIST SP 800-108. In another implementation, the derivation method can use a pseudo-random function which can be the HMAC based on SHA-256 as described in FIPS 198-1. However, other pseudo-random functions can be used, as long as they provide sufficient randomization to make it difficult to determine an encryption key. For example, the derivation method can use a tag such as a series to introduce randomization when generating an encryption key. Key generation information can be provided during the initialization of the client device or during manufacture. Key generation information is stored by each device in its own memory.
[21] [21] An authentication server on the network sends to each client device, over a secure channel, key configuration information that comprises a bypass key, a bypass index, an initial expiration period and an expiration interval. As well as the key generation information provided, the key configuration information received by each client device is also stored by each device in its own memory.
[22] [22] In response to a client device receiving key configuration information, the client device independently generates an initial encryption key. The initial encryption key is generated by each client device based at least in part on the bypass method that was provided to the client device and on key configuration information, including without limiting the bypass key and bypass index. that were previously received from the authentication server.
[23] [23] Since the same derivation method and the same key configuration information were provided for each client device, the initial encryption key generated by each device is common to or the same for all client devices. The initial encryption key is valid until the initial expiration period that has been provided for each client device expires. It is noted that the most recently generated encryption key is the one used by the device to verify messages and also to encrypt and decrypt messages, so the initial encryption key can become the current encryption key. The terminology of "initial encryption key" is used in this application for ease of reference in explaining the generation of encryption keys that are generated at different times.
[24] [24] The authentication server comprises a processor and memory and also generates an initial encryption key which, when generated, is the same as the initial encryption key that is generated independently by each client device. To do this, the authentication server is provided with the same key generation information that is provided for each client device. The authentication server stores the key generation information in its own memory. Additionally, the authentication server keeps the same key configuration information in its memory. Therefore, the authentication server can generate an initial encryption key based at least in part on the provided derivation method and key configuration information. The initial encryption key generated by the authentication server is the same as that generated by each client device and is valid until the initial expiration period expires.
[25] [25] Each device on the network independently generates an initial encryption key, including multiple client devices and the authentication server. Although each device independently generates its own initial encryption key, the initial encryption key for all devices is the same. It is observed that the initial expiration period received by all client devices and maintained by the authentication server is also the same; therefore, all devices on the network are synchronized to communicate securely using the initial encryption key until the end of the initial expiration period.
[26] [26] In response to a device, or a client device or the authentication server, determining that the initial expiration period has already expired, the device generates a new encryption key. Since all devices determine expiration using the same initial expiration period, all devices simultaneously determine that the initial expiration period has already expired. Once the initial expiration period has expired, several steps are taken by the devices to generate a subsequent encryption key. A current derivation index is generated by each device using the derivation index received previously from the authentication server and the provided derivation index setting. A current expiration period for the subsequent encryption key is generated based on the initial expiration period and the expiration interval previously received from the authentication server,
[27] [27] Once a current derivation index is generated, a subsequent encryption key is generated based at least in part on the derivation method provided, the derivation key previously received from the authentication server and the current derivation index. As with the initial encryption key, although the subsequent encryption key is generated by each device independently, the subsequent encryption key is the same for devices on the network. The most recently generated subsequent encryption key can become the current encryption key.
[28] [28] Similar to the initial encryption key, the current encryption key is valid until the end of the current expiration period. It is noted that the current expiration period generated by all devices is generated using the initial expiration period and the expiration interval provided by the authentication server. This information is stored and maintained independently by each device, but since it was provided by the authentication server to the client devices on the network, the information is the same on the devices. Therefore, all devices on the network are synchronized to communicate securely using the current encryption key until the end of the current expiration period.
[29] [29] In response to a device determining that the current expiration period has already expired, the device generates another new encryption key using the same method as described above. This includes updating the current derivation index by adjusting the derivation index, updating the current expiration period by the expiration interval and generating the next subsequent encryption key based on the derivation method, the derivation key and the updated derivation index . The next subsequent encryption key becomes the current encryption key and will be valid for the current updated expiration period. And again, when a device determines that the current updated expiration period has already expired, the device generates a subsequent subsequent encryption key that becomes the current encryption key as described above.
[80] [80] This iteration of the generation of subsequent encryption keys, which become the current encryption key and are valid for the current expiration period, can continue indefinitely and is performed independently by each device, as each device stores and maintains the key generation information, the key configuration information and any other information that is generated by each device such as the current lead index and the current expiration period.
[81] [81] In some embodiments, the encryption key, either the initial encryption key or a subsequent encryption key, is generated based on a derivation method. All devices can use the same bypass method to generate a common encryption key. As is known in the art, additional information can be provided for the derivation method such as the number of iterations to perform or the length of the key to be generated. The derivation method used must provide sufficient randomization to determine a subsequent encryption key, even if the current encryption key becomes known. If additional information is to be provided for the derivation method, the additional information that each device would provide for the derivation method to generate an encryption key should be such as to ensure that the same encryption key is generated by the multiple devices on the network.
[32] [32] In other embodiments, if the bypass method yield length exceeds the desired length of the encryption key, then the client device can use only a portion of the bypass method yield. For example, if the desired length is 128 bits and the derivation method yield is 256 bits, then the first 128 bits can be used as the encryption key. The desired length is predetermined and can be provided for the devices together with the bypass method and the bypass index adjustment. CRYPTOGRAPHY KEY RECOVERY
[833] [833] If one of the client devices is unable to verify messages from another client device using the current encryption key, the devices may attempt to synchronize the current bypass index to generate a valid current encryption key. By synchronizing its current bypass index, a client device can ensure that its current encryption key is compatible with the current encryption key of the other client devices without requiring any exchange with the authentication server.
[384] [384] For example, if Device A sends a message to Device B and Device B cannot verify the message from Device A, the following steps can be taken to synchronize the current derivation index of Device A and Device B For this example, the current derivation index is increased with the value of the derivation index adjustment; therefore, with each iteration that generates a subsequent encryption key, the current derivation index is incremented by a predetermined amount. This predetermined quantity is the derivation index adjustment. The steps are as follows:
[835] [835] * Device B receives message from Device A.
[36] [36] * Device B cannot verify message from Device A using the current encryption key from Device B.
[87] [87] * Device B will attempt to verify the message using a test encryption key that is generated using its current derivation index with the increment of the derivation index setting. Therefore, Device B generates a test encryption key using its own derivation index incremented by the derivation index setting. If the message verification from Device A is successful using the test encryption key, Device B adopts the test encryption key as its own current encryption key and adopts the incremented derivation index as its current derivation index. . If the message that Device B received from Device A contains information to update the current derivation index of B, Device B stops processing the message received from Device A.
[88] [88] * If the verification of A's message is not successful using the test encryption key generated by incrementing B's current derivation index, then Device B generates a different test encryption key using its index current derivation rate decreased by adjusting the derivation index. Therefore, B generates a test encryption key using its own derivation index decremented by the derivation index adjustment. Successful verification of the message from Device A using this test encryption key may mean that Device A is using the value of the previous derivation index as its current derivation index. Device B would send Device A a message that is encrypted with Device B's current encryption key. When Device A receives this message from Device B, Device A will not be able to verify this message and Device A will begin retrieving your own encryption key.
[839] [839] * If verification of A's message is unsuccessful using the test encryption key generated by decrementing B's current derivation index, then Device B generates a different test encryption key using a key lead and its current lead index. If Device B does not have a previous bypass key, Device B disregards the message from Device A. If verification of the message from Device A is successful using the test encryption key generated using the previous bypass key, then Device À is using a previous bypass switch. Device B sends a message to Device A to update its encrypted bypass key using the test encryption key so that the
[40] [40] * If message A's verification is not successful using the test encryption key generated using a previous derivation key and its current derivation index, Device B disregards the message from Device A.
[41] [41] Encryption key recovery can also be performed if a client device has experienced a loss of power. Once a device has experienced a loss of power, its internal clock may no longer have the current device time. In one mode, a client device that has experienced a crash and goes online can retrieve the encryption when it receives a message containing the current time. Such a message can be a flag message that contains an authentication code that can be verified using the current encryption key.
[42] [42] When a device that goes online receives a flag message, it will try to verify the authentication code of the flag message using its current encryption key. If the check is successful, the device can accept the time designated in the flag message as its current device time. Thus, the device has the current branch key, the current branch index, the current expiration period and the current encryption key.
[43] [43] If the flag message verification fails, the device calculates the number of expiration intervals that have expired since the power loss. This can be calculated using the time in the flag message, the current expiration period and the expiration interval. If the flag message does not contain the time, the device can use one as the number of expiration intervals that have expired since its power loss.
[44] [44] The current lead rate is increased by the number of intervals that have expired since the device lost power. A subsequent encryption key is generated using the current bypass key and the current bypass index which has been increased by the number of intervals that have expired since the power outage. If the verification of the flag message is successful using the subsequent generated encryption key, the device accepts the time on the flag. Additionally, the device generates a current expiration period based on the current expiration period and the expiration interval. The device also updates its current values by the current derivation index and the current encryption key for those recently generated.
[45] [45] If verification of the flag message fails with the newly generated subsequent encryption key, the flag message is disregarded. In this example, since the device received a flag message it recognizes that there is a neighboring device. If, after a predetermined time (that is, 30 seconds), it does not have the capacity to obtain a valid time, it can generate a time that is random during the next 24 hours. In this generated time, it starts the authentication with the authentication server. The time to initiate authentication with the authentication server is random so that all devices do not attempt to authenticate at the same time.
[46] [46] In the examples given above, client devices can be meters on a network that can be used by utility companies and other resource providers to monitor, control and measure resource consumption by consumers. The present invention will now be described with reference to the accompanying drawings, in which the exemplary embodiments of the invention are shown.
[47] [47] Figure 1 is an example of configuring an authentication server and client devices on a network. Authentication server 120 communicates with multiple client devices 131 to 134 on network 110. Any client device 131 to 134 can communicate with any other client device 131 to 134 or authentication server 120 over the network
[48] [48] Devices on the network include, but are not limited to, an authentication server 120 and client devices 131 to 134. For secure communication between devices 120, 131 to 134 on network 110, the devices use an encryption key to encrypt messages that are sent and decrypt messages that are received. To provide additional security, the encryption key is updated periodically by each device. However, the updated encryption key is the same on devices 120, 131 to 134 to allow message encryption and decryption by all devices 120, 131 to 134 on network 110.
[49] [49] With reference to Figure 2, authentication server 120 comprises processor 211 and memory 213. Processor 211 of authentication server 120 executes instructions stored in memory
[50] [50] Additionally, the authentication server keeps additional information in its memory to generate encryption keys. This additional information includes key configuration information including, but not limited to, a derivation key 241, a derivation index 242, an expiration period 244 and an expiration interval 245. As well as key generation information, Key configuration information can be provided to the authentication server at installation or manufacturing. The authentication server also comprises a 251 clock that maintains the current device time by the authentication server. The clock that maintains the current device time by the authentication server can be set during the initialization or installation of the authentication server. Additionally, it can be configured or reconfigured with the receipt of a message containing the current time.
[51] [51] There may be multiple client devices 131 through 133 on the network. Each client device 131 to 133 comprises a processor 221, 222, 223 and memory 231, 232, 233, respectively. Each processor 221 to 223 executes instructions stored in the respective memory 231 to 233 of the client device 131 to 133. In this example, the client device 131, the client device 132 and the client device 133 are assumed to be similar. Thus, descriptions regarding a client device are applicable to all client devices 131 to 133.
[52] [52] Each client device 131 to 133 is provided with key generation information including, but not limited to a bypass method 246, 246 ”and 246”, a bypass index setting 243, 243 'and 243 ” . It is noted that the derivation method 246 provided to the authentication server 120, the derivation method 246 'provided to the client device 131, the derivation method 246 ”provided to the client device 132 and the derivation method 246” provided to the client. client device 133 are the same. Similarly, the derivation index setting 243 that is provided to authentication server 120 and the derivation index setting 243 ', 243 "and 243” that is provided by each of the client devices 131 to 133 are the same Each device 120, 131, 132, 133 independently stores and maintains the key generation information that is common to devices 120, 131, 132, 133 on network 110. In addition, each client device comprises a 251 'clock, 251 ”and 251” which maintains the current device time for each client device. The current device time for each device can be initially configured during installation or initialization of the client device. In addition, it can be configured with the receiving a message that includes the current time. This message can be received from the authentication server or another client device. An example of a type of message that contains the current time is a flag message.
[583] [583] As an additional reference, the common reference numbers with misleading signs in Figure 2 denote common information that is stored and maintained independently for each device. For example, with reference to Figure 2, the bypass key 241 on the authentication server, the bypass key 241 'of the client device 131, the bypass key 241 "of the client device 132 and the bypass key 241" of the client. client device 133 are all the same. However, each device maintains its own copy of this information in its respective memory 231 to 233.
[54] [54] To generate an encryption key that is common to devices on network 110, any client device 131 to 133 on the network requests the establishment of a secure channel between client device 131 to 133 and authentication server 120. For For example, client device 131 may request that a secure channel be established between itself and authentication server 120. Authentication server 120 then transmits a message to client device 131. This message includes key configuration information , including but not limited to branch key 241, branch index 242, expiration period 244 and expiration interval 245. Client device 131 stores and maintains this information independently in its memory 231 as a key bypass 241 ', bypass index 242', expiration period 244 'and expiration interval 245'. It is noted that the key configuration information transmitted to any device 131 to 133 of the authentication server 120 is the same. In other words, the key configuration information stored and maintained by each device is common to all devices. As well as key generation information, each device 120, 131, 132, 133 independently stores and maintains the key configuration information that is common for devices 120, 131, 132, 133 on network 110.
[55] [55] Since client device 131 determines that it has received key configuration information, client device 131 generates an initial encryption key 248 'based at least in part on the provided derivation method 246' and the key configuration information received previously comprising branch key 241 'and The Branch Index 242'. This process that generates an initial encryption key 250 'is common to all client devices 131 to 133 and therefore, since each client device 131 to 133 independently determines that it has received configuration information from authentication server key 120, it will generate its own initial encryption key 250 ', 250 ”and 250" ”' which is common to all devices 131 to 133. In other words, the initial encryption key 250 'that is generated independently by the client device 131 will be the same as the initial encryption key 250 "which is generated by the client device 132 and the same as the initial encryption key 250" which is generated by the client device
[56] [56] It is observed that the initial encryption key 250, 250 ”and 250” becomes the current encryption key. That is, the initial encryption key is the encryption key that is currently used by all devices until the expiration period 244 ', 244 "and 244" ”'., Each device can store the initial encryption key 250 ', 250 "and 250" separate from the current encryption key 248, 248 "and 248". Alternatively, a device can store and maintain the initial encryption key as the current encryption key. In this mode, not shown, the device's memory will not it would include an initial encryption key since the initial encryption key would be stored and maintained as the current encryption key.
[57] [57] Authentication server 120 can also generate its own initial encryption key 250 in the same way that client devices generate their initial encryption keys. Since the information required to generate the initial encryption key is the same on devices, the initial encryption key 250 generated by the authentication server has the same value as the initial encryption key 250 ', 250 ", 250" generated independently by each client device 131 to 133. Similarly, authentication server 120 can store and maintain the initial encryption key as a current encryption key.
[58] [58] The initial encryption key 250 is valid until the expiration of the expiration period 244 that was received from the authentication server 120 and stored separately by each client device 121 to 133 as 244, 244 ”, 244” in its own memory 231 to 233, respectively. Therefore, any client device 131 to 133 can determine whether expiration period 244 has already expired. When the client device 131 determines that the expiration period 244 'has already expired, it will generate a current derivation index 247' by modifying the derivation index 242 'previously received from authentication server 120 by adjusting the derivation index 243' that was previously provided. Other client devices 132, 133 can also determine when the expiration period 244 has already expired using their own expiration period 244 ”, 244" and they will also generate a current derivation index 247 ”and 247” which will be the same in devices 131 to 133.
[59] [59] Authentication server 120 can also determine when its initial encryption key 250 expires by determining whether its expiration period 244 has already expired. Thus, the initial encryption key 250, 250, 250 ”and 250" for all devices expires simultaneously, since the expiration periods 244, 244 ', 244 "and 244"' are the same.
[60] [60] In addition to generating a current derivation index 247, the client device 131 will also generate a current expiration period 249 'based on the expiration period 244' and the expiration interval 245 'previously received from the authentication server 120 Similarly, authentication server 120 and other devices 132 to 133 will also generate their current expiration period 249, 249 "and 249" in the same way and therefore the current expiration period generated by all devices is the same.
[61] [61] Along with the generation of a current derivation index 247 'and a current expiration period 249', upon determining that the expiration period 244 'has expired, the client device 131 generates a subsequent encryption key based on less in part in the derivation method 246 'provided, in derivation key 241' previously received from authentication server 120 and in the current derivation index 247. This newly generated subsequent encryption key becomes the current encryption key 248 'and is valid until the current expiration period 249. This same procedure is followed by all other devices on the network to generate their respective current encryption keys 248, 248 ”, 248” which will be valid for the current expiration period 249, 249 ”and 249 ”.
[62] [62] Devices on network 110 including authentication server 120 and client devices 131 to 133 are synchronized to generate encryption keys by obtaining information common to all devices. This common information includes, but is not limited to branch key 241, branch index 242, branch index adjustment 243, expiration period 244, expiration interval 245, branch method 246, branch index current derivation 247 and current expiration period 249. Although this information is maintained independently by each device, it is common among devices. This synchronization through the use of common information allows each device to independently generate a current encryption key that is common among the devices on the network.
[63] [63] The current encryption key 248 is valid until the current expiration period 249. When a device determines that the current expiration period 249 has expired, subsequent encryption keys are generated. Each subsequent encryption key is valid for a respective expiration period. For example, when device 131 determines that the current encryption key 248 'is no longer valid because the current expiration period has been reached, the client device 131 will generate a subsequent subsequent encryption key and a corresponding expiration period. for the next subsequent encryption key generated. The next subsequent encryption key becomes the current encryption key 248 'and the respective expiration period becomes the current expiration period 249'.
[64] [64] To generate a subsequent subsequent encryption key, device 131 generates a new bypass index by modifying the current bypass index 247 'which it maintains in its memory 231 by adjusting bypass index 243'. For example, if the value of the derivation index setting 243 'is one, then the value of the new derivation index would be the value of the current derivation index 247' incremented by one. The current derivation index 247 'can be updated to the value of the new derivation index. Therefore, client device 131 has an updated current bypass index 247 'to be used in the generation of the next subsequent encryption key.
[65] [65] Additionally, device 131 generates a respective expiration period for the next subsequent encryption key. The respective expiration period is generated based on the current expiration period 249 'that device 131 keeps in its memory 231 and the expiration interval 245' previously received from the authentication server and kept in memory 231 on device 131. The respective period Expiry is the expiration period for the next subsequent encryption key that will be generated as explained below. Therefore, the current expiration period 249 'is updated to the value of the respective expiration period. The client device 131 now has an updated current derivation index 247 'and a current expiration period 249.
[66] [66] Client device 131 generates the next subsequent encryption key based at least in part on the derivation method 246 'provided, the derivation key 241' received from the authentication server and the current derivation index 247 'calculated by client device. The value of the current encryption key 248 'is replaced by the value of the next subsequent encryption key. In other words, the current encryption key 248 'is updated to the next subsequent encryption key. The client device 131 now has a current updated encryption key 248 'which is valid until the current expiration period 249' expires.
[67] [67] Once the current expiration period expires, the cycle of updating the current derivation index 247 ', updating the current expiration period 249' and generating a next subsequent encryption key that becomes the current encryption key 248 'is repeated. Each device on the network follows this procedure of generating its own current encryption key 248, 248, 248 ”and 248” whenever the current expiration period 249, 249 ', 249 ”and 249” expires. This allows devices on the network to independently generate a current encryption key 248, 248 ', 248 ”and 248” which is common across devices and can be used for secure communication between devices.
[68] [68] Figure 2 shows each device with a lead index 242, 242 ', 242 ”and 242” and a current lead index 247, 247', 247 ”and 247”. It is observed that a device can store and maintain only one derivation index which would be the derivation index currently used to generate the current encryption key. Thus, each time the derivation index is updated it would be stored as the current derivation index, thereby replacing the previous current derivation index. Similarly, each device may or may not maintain both an expiration period 244, 244 ', 244 ”and 244” and a current expiration period 249, 249', 249 ”and 249”. In this mode, the initial expiration period previously received from the authentication server can be stored and maintained as the current expiration period. In addition, each time an expiration period is generated; it would be stored and maintained as the current expiration period replacing a previous current expiration period. Each device can also store and maintain only one current encryption key 248, 248 ', 248 "and 248”. Similarly, each device may or may not maintain an initial 250, 250, 250 "and 250" encryption key and one current encryption key 248, 248 ', 248 ”and 248”. In this mode, the initial encryption key can be stored and maintained as the current encryption key. As a subsequent encryption key is generated, it would replace the current encryption key.
[69] [69] Figure 3 illustrates a process 300 for generating an initial encryption key and subsequent encryption keys that are common to devices on a network. A secure channel between an authentication server and a client device is established in step 310. The request to establish the channel can be initiated by the server or the client device.
[70] [70] After the secure channel is established, the authentication server transmits through the secure channel configuration information including, but not limited to, a bypass key, a bypass index, an expiration period, and an expiration interval for the client device in step 320.
[711] [711] In response to the client device receiving key configuration information, in step 330, the client device generates an initial encryption key based on the derivation method provided and the derivation key and the derivation index received from the server in step 320. The initial encryption key is valid and can be used for secure communication on network devices until the expiration period expires.
[72] [72] In step 340, the client device determines whether the expiration period has already expired. If the expiration period has not expired, the initial encryption key is valid and the client device continues to use the initial encryption key in step 350.
[73] [73] If the expiration period has already expired, the client device generates a current bypass index with a modification of the derivation index previously received from the authentication server by adjusting the bypass index in step 360. Additionally, the client device generates in step 370 a current expiration period based at least in part on the expiration period and the expiration interval previously received from the authentication server in step 320. The steps of generating a current derivation index in step 360 and the generate a current expiration period at step 370 can be performed in a different order. In one embodiment, the expiration period can be generated before or after generating the current derivation index.
[74] [74] In step 380, a subsequent encryption key is generated, since the initial encryption key is no longer valid. The subsequent encryption key is generated based at least in part on the derivation method provided, the derivation key previously received from the authentication server in step 320 and the current derivation index. Each subsequent encryption key is common to the devices on the network and valid until the current expiration period expires. The most recently generated subsequent encryption key is the current encryption key. This most recent subsequent encryption key that becomes the current encryption key is valid until the current expiration period expires.
[75] [75] When the client device determines that the current expiration period has already expired, steps 360 to 380 are repeated to periodically generate subsequent encryption keys. Since all the information required by the client device to generate subsequent encryption keys is stored and maintained by the client device, the client device independently generates subsequent encryption keys that are valid for use in secure communication with other devices on the network.
[76] [76] Figures 4A and 4B illustrate a process 400 for retrieving the encryption key currently being used among devices on a network. This process is aimed at retrieving the current encryption key by a client device without the need for any communication to or from the authentication server generating test encryption keys. Through the use of test encryption keys, a device can synchronize its current derivation index and its current expiration period with The valid current derivation index and the current valid expiration period that are currently used by devices on the network to generate a current valid encryption key.
[77] [77] For example, in step 410, Device B receives a message from Device A. Device B is unable to verify the message received from Device A using the current encryption key from Device B.
[78] [78] In this example, in response to Device B's inability to verify the message received using its current encryption key, Device B generates a test encryption key in step 420. The test encryption key is generated using a test lead index. The test derivation index is generated by increasing the derivation index by adjusting the derivation index. Thus, this test encryption key is the subsequent encryption key that Device B would generate once the current expiration period has expired.
[79] [79] Successful verification of the message by Device B using the test encryption key in step 430 means that Device B replaces its current encryption key with the test encryption key,
[80] [80] Referring to Figure 4B, successful verification of the message by Device B using the second test encryption key in step 450 means that Device A may be using the previous encryption key. Thus, Device B sends Device A a message encrypted with Device B's current encryption key in step 480. When Device A receives this message from Device B, it can begin its own encryption key recovery process. . If verification of the message using the second test encryption key is not successful in step 460, Device B would generate a third test encryption key using an earlier bypass key. A previous bypass key can be the bypass key used by Device B before the currently used bypass key. If Device B does not store previous branch keys, the message from Device A can be disregarded or ignored.
[81] [81] Successful verification of the message by Device B using the third test encryption key in step 490 means that Device A may be using an earlier bypass key. Thus, Device B sends to Device A a message that comprises the values of the current derivation key of Device B, the current derivation index of Device B and the current expiration period of Device B as shown in step 495. This message Device B can be encrypted using the third test encryption key. When device A receives this message, it decrypts it to obtain the significant values for Device A to update its current bypass key, its current bypass index and its current expiration period for those received in the message from Device B.
[82] [82] If there is no successful verification of the message by Device B using the third test encryption key, Device B can disregard the message as shown in step 485.
[83] [83] Figure 5 illustrates a process 500 for recovering the encryption key when the device experienced a power outage or any other condition that would not allow the device to maintain a current device time. In this example, in step 510 the device gains power after a fall and does not have a current device time. The device receives a message that includes a current time. This message can be received in a flag message. A flag message contains an authentication code that can be verified using the current encryption key.
[84] [84] In step 520, when a device that comes online receives a flag message, it will attempt to verify the flag message using its current encryption key. If the verification is successful, in step 570 the device can accept the time designated in the flag message as the current device time. In addition, since the verification was successful, the device has the current derivation key, current derivation index, current expiration period, and current encryption key.
[85] [85] If the verification of the flag message fails, in step 530, the device calculates the number of expiration intervals that have expired since it lost power. This can be calculated using the time received in the flag message, the current expiration period and the expiration interval. If the flag message does not contain the time, the device can use one as the number of expiration intervals that have expired since its power loss.
[86] [86] In step 540, the device adjusts its current bypass index by the number of expiration intervals that have expired since it lost power. The current lead rate can be adjusted by increasing it with the number of intervals that have expired since the device lost power. The device then generates a subsequent encryption key using the current derivation key and the current derivation index that has just been adjusted. If the verification of the flag message is successful using the subsequent generated encryption key, the device can accept the time in the flag message as its current device time in step 580. Additionally, the device can generate a current expiration period based on the current expiration period and the expiration interval. The device updates its current values by the current derivation index and the current encryption key for the newly generated one.
[87] [87] If the flag message verification fails with the newly generated subsequent encryption key, the flag message is disregarded. In this example, in step 560, since the device received a flag message it recognizes that there is a neighboring device. If, after a predetermined time (that is, 30 seconds), it is unable to obtain a valid time, it generates a time that is random during the next 24 hours. At that generated time, it starts authentication with the authentication server to receive key configuration information to generate a current encryption key. The time to start authentication with the authentication server should be random so that all devices do not attempt to authenticate at the same time. GENERAL CONSIDERATIONS
[88] [88] These examples given are for illustrative purposes only and are not intended to limit the invention to such devices. Although this matter has been described in detail in relation to its specific aspects, it will be verified that those skilled in the art, upon obtaining an understanding of the aforementioned, can promptly produce changes to, variations of and equivalent to such aspects.
Consequently, it should be understood that the present disclosure has been presented for purposes of examples rather than limiting and does not exclude the inclusion of such modifications, variations and / or additions to the present matter as will be readily apparent to an individual of ordinary skill in the art.
In particular, the steps taken to generate a derivation index or an expiration period or an encryption key do not necessarily have to be performed in the order specified.
For example, the expiration period can be generated or updated before or after the derivation index is generated.
In addition, the derivation index can be generated or updated at the expiration of the expiration period, or it can be generated or updated at any time after the encryption key is generated.
The derivation index adjustment is not limited to increments or decrements, but you can adjust the derivation index in other ways.

权利要求:
Claims (19)
[1]
1. Method for generating encryption keys by a client device, characterized by the fact that the client device is one of a plurality of client devices in a network and each client device is provided with key generation information that comprises computer executable instructions for a derivation method and a derivation index setting, which comprises: establishing a secure channel between an authentication server and the client device; receiving, from the authentication server through the secure channel, key configuration information comprising a bypass key, a bypass index, an initial expiration period and an expiration interval; in response to the client device receiving the key configuration information, generating an initial encryption key using the derivation method, the derivation key and the derivation index, where the client device uses the initial encryption key to encrypt a message to at least one of the plurality of client devices on the network before the initial expiration period expires; and in response to the client device determining that the initial expiration period has already expired: generating a current drop index with the drop index adjustment previously received from the authentication server by the drop index adjustment; generate a current expiration period based on the initial expiration period and the expiration interval previously received from the authentication server; and generate a subsequent encryption key using the derivation method, the derivation key previously received from the authentication server, and the current derivation index, where the subsequent encryption key is valid until the current expiration period expires.
[2]
2. Method, according to claim 1, characterized by the fact that it additionally comprises: in response to the client device determining that the current expiration period has already expired: adjusting the current derivation index by adjusting the derivation index; update the current expiration period by the expiration interval previously received from the authentication server; and generate a next subsequent encryption key using the derivation method, the derivation key previously received from the authentication server, and the current derivation index, where the next subsequent encryption key is valid until the current expiration period expires.
[3]
3. Method, according to claim 1, characterized by the fact that the client devices are utility meters.
[4]
4. Method, according to claim 1, characterized by the fact that the derivation method and the derivation index adjustment are provided for each of the client devices during installation or manufacture.
[5]
5. Method, according to claim 1, characterized by the fact that the derivation method is based on a pseudo-random function.
[6]
6. Method, according to claim 1, characterized by the fact that the initial encryption key and the subsequent encryption key are truncated by the client device to a predetermined extent when they exceed the predetermined extent.
[7]
7. Method, according to claim 5, characterized by the fact that the key configuration information additionally comprises several iterations and in which generating the initial encryption key or the subsequent encryption key comprises iterating the pseudo-random function and the number of iterations.
[8]
8. Method, according to claim 7, characterized by the fact that the pseudo-random function is HMAC based on SHA-256.
[9]
9. Method, according to claim 1, characterized by the fact that the derivation index is an integer and the client device converts the whole number into a binary series before using it with the derivation method.
[10]
10. Method, according to claim 1, characterized by the fact that generating the initial encryption key further comprises using a markup with the derivation method.
[11]
11. Method for retrieving a current encryption key for a first client device from a second client device, where the first client device stores a current first encryption key, first key information that comprises a first index of current derivation, a first derivation key, a first derivation method, a first derivation index adjustment, a first current expiration period and an expiration interval, and the second client device stores a second current encryption key, being that the method is characterized by the fact that it comprises: receiving an encrypted message by the first client device, the encrypted message being sent by the second client device, the message being encrypted using the current second encryption key; in response to the determination by the first client device that the current first encryption key fails to verify the message received from the second client device, generate a test encryption key using the first bypass method, the first bypass key , and the first current derivation index with the increment of the first derivation index adjustment; in response to the determination by the first client device that the test encryption key successfully verifies the message received from the second client device, replace the current first encryption key with the test encryption key, adjust the current current bypass index incrementing it with the first derivation index adjustment and adjusting the first current expiration period by the expiration interval.
[12]
12. Method, according to claim 11, characterized by the fact that it further comprises: in response to the determination by the first client device that the test encryption key fails to verify the message received from the second client device, generate a second test encryption key using the first bypass method, the first bypass key, and the first current bypass index with decrement of the first bypass index setting; in response to the determination by the first client device that the second test encryption key successfully verifies the message received from the second client device, the first client device sends a message to the second encrypted client device using the first encryption key. current encryption.
[13]
13. Method, according to claim 12, characterized by the fact that it further comprises: in response to the determination by the first client device that the second test encryption key fails to verify the message received from the second client device, generate a third test encryption key using the first bypass method, a first previous bypass key and the first current bypass index; and in response to the determination by the first client device that the third test encryption key successfully verifies the message received from the second client device, the first client device sends a message to the second client device encrypted using the third key test cryptography with the message comprising the first bypass key, the first current bypass index, and the first current expiration period.
[14]
14. Method for retrieving a current encryption key by a client device that has experienced a power outage and does not have a current device time, with the client device storing key generation information that comprises computer executable instructions for a derivation method and a derivation index adjustment and key configuration information comprising a derivation key, a current derivation index, a current expiration period and an expiration interval, the method being characterized by the fact that comprises:
receive an encrypted message that comprises a current time; in response to the determination that the encrypted message fails to be verified using the current encryption key: determine several intervals expired since the power outage using the current received time, the current expiration period and the expiration interval; adjust the current branch index by the number of intervals expired since the power outage; generate a subsequent encryption key using the derivation method, the derivation key and the current derivation index; in response to the determination that the encrypted message can be verified using the subsequent encryption key, set the current device time to the current received time, update the current encryption key to the subsequent encryption key, and adjust the current expiration period based on the number of expired intervals.
[15]
15. Method, according to claim 14, characterized by the fact that it further comprises: in response to the determination that the encrypted message fails to be verified using the subsequent encryption key: establishing a secure channel between the client device and a authentication server at random time; receive, from the authentication server, through the secure channel, key configuration information; and generate the current encryption key using the key configuration information received from the authentication server.
[16]
16. Client device characterized by the fact that it comprises: a processor unit that includes a processor and processor unit memory, where the processor unit memory includes executable instructions by computer for the initialization of the client device and information of key generation comprising a derivation method and a derivation index adjustment; and where the processor is operable to execute executable instructions by computer from processor unit memory to: receive communication over a secure channel on a network, the communication containing key configuration information from an authentication server , the key configuration information comprising a branch key, branch index, initial expiration period and expiration interval; in response to receiving key configuration information, generate an initial encryption key using the derivation method, the derivation key and the derivation index, the initial encryption key being used to encrypt a message for at least one among a plurality of client devices on the network before the initial expiration period expires; in response to the determination that the initial expiration period has already expired: generate a current derivation index by adjusting the derivation index previously received from the authentication server by adjusting the derivation index; generate a current expiration period based on the initial expiration period and the expiration interval previously received from the authentication server; and generate a subsequent encryption key using the derivation method, the derivation key previously received from the authentication server, and the current derivation index, the subsequent encryption key being valid until the current expiration period expires.
[17]
17. Client device, according to claim 16, characterized by the fact that it additionally comprises: in response to the determination that the current expiration period has already expired: adjust the current derivation index by adjusting the derivation index; update the current expiration period by the expiration interval previously received from the authentication server; and generate a subsequent subsequent encryption key using the derivation method, the derivation key previously received from the authentication server, and the current derivation index, the next subsequent encryption key being valid until the current expiration period expires.
[18]
18. Client device, according to claim 17, characterized by the fact that the derivation index adjustment is one and the current derivation index is based on the increment of the current derivation index by the derivation index adjustment.
[19]
19. Client device, according to claim 16, characterized by the fact that the key generation information is provided either at startup or in the manufacture of the client device.

类似技术:

公开号 | 公开日 | 专利标题

BR112016010845A2|2020-08-18|? METHOD FOR GENERATING AND RECOVERING ENCRYPTION KEYS BY A CLIENT DEVICE?

US8364962B2|2013-01-29|Communication data freshness confirmation system

JP5975594B2|2016-08-23|Communication terminal and communication system

JP5878630B2|2016-03-08|Method and apparatus for virtual pairing with a group of semi-connected devices

US20200015087A1|2020-01-09|Reduced bandwidth handshake communication

JP5859956B2|2016-02-16|Key generation method and system in switching process

Dowling et al.2016|Authenticated network time synchronization

Pinto et al.2016|Hash-chain-based authentication for IoT

JP2016116134A|2016-06-23|Signature verification device, signature generation device, signature processing system, signature verification method, and signature generation method

US9455977B1|2016-09-27|Remote management interface using credentials associated with respective access control intervals

JP2016184892A|2016-10-20|Authentication method, authentication system and communication equipment

KR20150135032A|2015-12-02|System and method for updating secret key using physical unclonable function

JP5835162B2|2015-12-24|Cryptographic communication system and cryptographic communication method

US20190394174A1|2019-12-26|Automatic Client Device Registration

Liu et al.2019|Design of password encryption model based on AES algorithm

US20190280921A1|2019-09-12|Computing device and method for performing a fabric deployment in a data center

US10965453B2|2021-03-30|System and method for authenticated encryption based on device fingerprint

KR20160026101A|2016-03-09|System and method for updating secret key

JP6915717B2|2021-08-04|Communications system

KR20210126319A|2021-10-20|Apparatus and method for managing key

US11005667B2|2021-05-11|Computing device and method for performing a secure neighbor discovery

US11177967B2|2021-11-16|Template based credential provisioning

Jiang et al.2018|An internal node reprogrammable security scheme based on IEEE 802.15. 6 in wireless body area networks

KR20190040443A|2019-04-18|Apparatus and method for creating secure session of smart meter

EP2905717A1|2015-08-12|Device and method for device and user authentication

同族专利:

公开号 | 公开日

MX352389B|2017-11-22|

CA2928456C|2020-06-02|

MX2016005800A|2016-08-11|

WO2015073422A3|2015-09-03|

JP2016537888A|2016-12-01|

JP6511443B2|2019-05-15|

AU2014348876A1|2016-06-02|

US20150143108A1|2015-05-21|

US9425968B2|2016-08-23|

AU2014348876B2|2018-11-15|

WO2015073422A2|2015-05-21|

CA2928456A1|2015-05-21|

引用文献:

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

JP2001203682A|2000-01-24|2001-07-27|Advanced Mobile Telecommunications Security Technology Research Lab Co Ltd|Arithmetic operation saving type exclusive key share method|

US7657036B2|2004-09-21|2010-02-02|Qualcomm Incorporated|Determining a session encryption key during a broadcast/multicast service session using secure real-time transport protocol|

US9838365B2|2007-07-10|2017-12-05|Qualcomm Incorporated|Peer to peer identifiers|

JP5288901B2|2008-06-23|2013-09-11|三菱電機株式会社|Key management server, terminal, communication system, key distribution method, key distribution program, key reception method, and key reception program|

US8670946B2|2010-09-28|2014-03-11|Landis+Gyr Innovations, Inc.|Utility device management|

US9161216B2|2010-12-08|2015-10-13|Lg Electronics Inc.|Traffic encryption key management for machine to machine multicast group|

US9425968B2|2013-11-15|2016-08-23|Landis+Gyr Innovations, Inc.|System and method for updating an encryption key across a network|US10275840B2|2011-10-04|2019-04-30|Electro Industries/Gauge Tech|Systems and methods for collecting, analyzing, billing, and reporting data from intelligent electronic devices|

US10862784B2|2011-10-04|2020-12-08|Electro Industries/Gauge Tech|Systems and methods for processing meter information in a network of intelligent electronic devices|

US10303860B2|2011-10-04|2019-05-28|Electro Industries/Gauge Tech|Security through layers in an intelligent electronic device|

US10771532B2|2011-10-04|2020-09-08|Electro Industries/Gauge Tech|Intelligent electronic devices, systems and methods for communicating messages over a network|

GB201105765D0|2011-04-05|2011-05-18|Visa Europe Ltd|Payment system|

US9425968B2|2013-11-15|2016-08-23|Landis+Gyr Innovations, Inc.|System and method for updating an encryption key across a network|

US9922322B2|2013-12-19|2018-03-20|Visa International Service Association|Cloud-based transactions with magnetic secure transmission|

US10264476B2|2014-03-11|2019-04-16|Nec Corporation|Wireless communication device, frequency determination method for wireless communication device, and program therefor|

WO2015179637A1|2014-05-21|2015-11-26|Visa International Service Association|Offline authentication|

US9775029B2|2014-08-22|2017-09-26|Visa International Service Association|Embedding cloud-based functionalities in a communication device|

US20160218866A1|2015-01-27|2016-07-28|Qualcomm Incorporated|Group key announcement and distribution for a data link group|

CZ306210B6|2015-07-07|2016-09-29|Aducid S.R.O.|Method of assignment of at least two authentication devices to the account of a user using authentication server|

US10958435B2|2015-12-21|2021-03-23|Electro Industries/ Gauge Tech|Providing security in an intelligent electronic device|

US10430263B2|2016-02-01|2019-10-01|Electro Industries/Gauge Tech|Devices, systems and methods for validating and upgrading firmware in intelligent electronic devices|

US10601793B2|2016-03-11|2020-03-24|Pss, Llc|Systems and methods for securing electronic data with embedded security engines|

US10313123B1|2016-12-14|2019-06-04|Amazon Technologies, Inc.|Synchronizable hardware security module|

CN110166227A|2018-02-12|2019-08-23|开利公司|With the wireless communication of non-networked controller|

CN112153642B|2019-06-26|2022-02-22|天地融科技股份有限公司|Equipment authentication method in office environment, office equipment and system|

KR102274285B1|2019-07-01|2021-07-07|에스지에이 주식회사|An OTP security management method by using dynamic shared secret distribution algorithm|

法律状态:
2020-08-18| B15K| Others concerning applications: alteration of classification|Free format text: AS CLASSIFICACOES ANTERIORES ERAM: H04L 29/06 , H04L 9/08 , H04L 9/32 Ipc: H04L 9/08 (2006.01), H04L 29/06 (2006.01) |

2020-08-25| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

2021-11-03| B350| Update of information on the portal [chapter 15.35 patent gazette]|

优先权:

申请号 | 申请日 | 专利标题

US201361904829P| true| 2013-11-15|2013-11-15|

US61/904,829|2013-11-15|

PCT/US2014/064989|WO2015073422A2|2013-11-15|2014-11-11|System and method for updating an encryption key across a network|

[返回顶部]